home *** CD-ROM | disk | FTP | other *** search
/ Amiga Format CD 42 / Amiga Format AFCD42 (Issue 126, Aug 1999).iso / -serious- / emulation / c64gfx / man / bfli.txt < prev    next >
Text File  |  1999-05-14  |  16KB  |  421 lines
  1. --------------------------------------------------------------------------
  2. In This Issue:    BFLI - New graphics modes 2
  3.  
  4. FLI gave us more color to the screen, AFLI increased the horizontal
  5. resolution and partly the color selection by using the hires mode.
  6. BFLI stands for 'Big FLI' and gives us 400 lines instead of the
  7. usual two hundred.  AFLI and BFLI can be combined, but we are not
  8. going into that (yet ?).
  9.  
  10.     Pasi 'Albert' Ojala    albert@cs.tut.fi
  11. --------------------------------------------------------------------------
  12.  
  13.  
  14.  
  15.         BFLI - New graphics modes 2
  16.         ---------------------------
  17.  
  18.  
  19. One day I was watching some demos that used linecrunch routines for
  20. whole-screen multicolor-graphics upscrollers.  I already had my
  21. theories about how and why linecrunch worked, but because I had not
  22. used it anywhere, the details were a bit vague.  In fact, I have
  23. many times accidentally created linecrunch effects when trying to do
  24. something else with $D011.  Probably every demo coder has.
  25.  
  26. But you learn by doing.  I had the idea of using linecrunch for FLI
  27. instead of a simple multicolor picture as it always seemed to be
  28. used.  However, this has probably been done before and because I
  29. don't like to do things that have been done before, I decided to use
  30. linecrunch to show a two-screen-tall FLI picture.
  31.  
  32.  
  33. _Linecrunch Basics_
  34.  
  35. For those not familiar with linecrunch routines:  linecrunch is used
  36. to scroll the screen UPWARDS by convincing VIC-II that it has
  37. already showed more character rows than it in reality has shown.
  38. Surprisingly (or then, maybe not :) this consists of fiddling with
  39. $D011.  The timing is critical as always.
  40.  
  41. Linecrunch works by setting $D011 equal the line before the current
  42. line and VIC-II will happily think that it is time to move on to the
  43. next character row - add 40 to the video matrix counter, 320 to the
  44. graphics memory counter and be ready to start a bad line.  Or, maybe
  45. 'NOT to go back to the current row' would be a more suitable
  46. description.  (Programming VIC-II is slowly becoming a science.)
  47. The required timing also does not cause bad lines so that you can
  48. skip another character row immediately on the successive line.
  49.  
  50. Because linecrunch causes VIC-II to skip rows, it will run out of
  51. video matrix and color memory (and graphics memory) to show before
  52. reaching the end of the screen.  However, VIC-II does not stop
  53. displaying the graphics nor does it reset the internal counters.
  54. The counters keep on running and wrap around instead.
  55.  
  56. Normally, when VIC-II is displaying the last character row, it is
  57. showing the memory from offsets $3c0 to $3e7.  If VIC-II has skipped
  58. one character row, it is displaying from $3e8 to $40f instead.  But,
  59. there are only 10 bits in the video matrix counter (locations
  60. 0..1023), so it wraps around to zero after $3ff.  This means that
  61. the beginning of the video matrix is displayed at the bottom of the
  62. screen.  The character rows become shifted by 24 character positions
  63. to the right because there were originally 24 unused memory
  64. locations at the end of the memory (1000..1023).  (To be honest,
  65. sprite image pointers are not unused memory, but they are not used
  66. with normal FLI.)
  67.  
  68.      ____________________     ____________________
  69.     |abcdefghijklmnopqrst|    |abcdefghijklmnopqrst|
  70.     |                    |  |--------------------| <- Skipped row
  71.     :                    :    :                    :
  72.     :                    :    :                    :
  73.     :                    :    :                    :
  74.     |                    |  |normally last line  |
  75.     |normally last line  |  |XXXXXXXXZZZZabcdefgh|
  76.     `--------------------'  `--------------------'
  77.                 X = unused mem      (1000..1015)
  78.                 Z = sprite pointers (1016..1023)
  79.  
  80.     Figure 1: Linecrunch
  81.  
  82.  
  83. The same thing happens for color memory because it uses the same
  84. counter for addressing the memory (in fact, color memory access and
  85. character data access are performed simultaneosly, 12 bits at a
  86. time).  The graphics memory behaves the same way, except that the
  87. counter has three bits more and it counts at eight times the speed,
  88. so that it wraps at the exact same time as the other counter.
  89.  
  90.  
  91. _Back to BFLI_
  92.  
  93. Wrapped data is nothing difficult to work with.  It is just the
  94. matter of writing the right conversion program.  (Which still may be
  95. more than you can handle on the first attempt.  I made several
  96. attempts to get the file format right in the first place.  And the
  97. format has changed twice after that.) Also, the normal FLI routine
  98. can be used, we only have to make sure VIC always has the right bank
  99. visible - simple LDA bank,x:sta $DD00 can accomplish that.
  100.  
  101. The more difficult aspect is to make the display freely locatable.
  102. We have 33 kilobytes of graphics data, this is the main reason we
  103. can't even think about using copying.  Linecrunch combined with the
  104. bad line delaying technique will do the job much more nicely.
  105.  
  106. Figure 2 shows the principles.  To make things simpler I have chosen
  107. location 0 to mean that the top of the picture is visible, 1 means
  108. that the picture is scrolled one line upwards and so on.  We can see
  109. that linecrunch is not used at all for the location 0.  To make the
  110. picture start at the same point whether linecrunch has crunched
  111. lines or not we compensate the non-lost raster lines by delaying the
  112. next bad line.  When the location is n*8 (n=0,1,2..), the sum of the
  113. linecrunched and delayed lines is constant - the graphics display
  114. always starts at the same point.
  115.  
  116. Then how do we deal with the location values that are not evenly
  117. dividable by eight ?  Now, lets assume that the location is L, and
  118. we have C, which is the location divided by eight (C = L/8), and R,
  119. which is the remainder (R = L%8).  To make the picture scroll to the
  120. right position, we need to delay the bad line less than before - R
  121. lines less for location L than for location C*8.  E.g.  for location
  122. 2 we delay the bad line two lines less than for location 0.  This
  123. also shows that we need 7 lines more than is needed for to
  124. compensate for the linecrunch.
  125.  
  126. Determining the number of linecrunch lines is a recursive process,
  127. because when you use more linecrunch lines, that decreases the
  128. number of lines you have available for the display and you need
  129. bigger range for the location value.  We lose about two lines when
  130. we use the soft y-scroll with the linecrunch and the 7 lines used in
  131. the soft y-scroll itself.  This makes 191 lines available for the
  132. display originally.
  133.  
  134. Because we need to show 400 lines of graphics, we would need
  135. (400-191)/8=27 linecrunch lines.  However, this in turn reduces the
  136. number of lines we have for graphics to 191-27=164 and we need
  137. (400-164)/8=30 linecrunch lines.  Again, 191-30 is 161.  We get
  138. (400-161)/8=30 and there it finally converges and we have 161 lines
  139. for graphics, which makes location values 0..238 valid.
  140.  
  141.  
  142. Location    0    1    2  ..    8    9  ..    238
  143.  
  144.         ___________________..   ___________..    ________
  145. Linecrunch    -------------------..   ___________..
  146.         ^    ^    ^
  147.         |    |    |    ^    ^
  148.         |    |    |    |    |
  149. Bad line delayed|    |    |    |    |
  150.         |    |    |    |    |    ========
  151.         |    |    v    |    |    232
  152.         |    v    ___..   |    v    :
  153.         v    ________0    v    ___..    :
  154. Gfx Enabled    ________0_______1__..   ________8__..    237_____
  155.         0    1    2    8    9    238
  156.         1    2    3    9    10    239
  157.         2    3    4    10    11    240
  158.         3    4    5    11    12    241
  159.         4    5    6    12    13    242
  160.         5    6    7    13    14    243
  161.         6    7    8    14    15    244
  162.         7    8    9    15    16    245
  163.         :    :    :    :    :    :
  164.         :    :    :    :    :    :
  165.         160    161    162..    168    169..    399
  166.  
  167.     Figure 2: Linecrunch and DMA delay in BFLI
  168.           (Graphics lines not in scale)
  169.  
  170.  
  171. _Clipping added_
  172.  
  173. Now we can scroll the picture to any location we want, but the top
  174. of the picture is not clipped and it is very annoying to watch.
  175. (Change AND #$77 to AND #$37 inside LOOP 0 to see what I mean.)
  176. We need to enable the graphics at the same point regardless of the
  177. y-scroll value.  The answer is in the extended color mode (ECM).
  178.  
  179. When both ECM and multicolor mode (MCM) are selected, VIC-II will
  180. turn the display to black.  This is because there is a conflicting
  181. situation and it just can't decide which color scheme to use.  The
  182. video accesses will continue to happen just like before, the data is
  183. just not displayed.  When the ECM bit is cleared again, the normal
  184. multicolor graphics is again shown.
  185.  
  186. So, we set the ECM bit and start to display the first eight lines of
  187. the FLI.  Because the FLI rout